Amiga Magazin: Amiga-CD 1996 March/Amiga-CD 1996 #3.iso/demos/stormc-demo/liesmich

Text File | 1996-01-19 | 23.6 KB | 591 lines

Willkommen zur StormC-Demoversion 1.0

Bereits zur Computer 95 im letzten November war eine Vorversion unseres
neuen Compilersystems erhältlich. Die verwirklichten Konzepte und
eingeflossenen neuen Innovationen haben auch die Presse überzeugt, wie
Sie in einigen Berichten in den Januar- und Februar-Ausgaben der gängigen
Amiga-Zeitschriften nachlesen können.

Hier nur einige Auszüge:

Amiga Plus 1/96

   Neue Konzepte bei Entwicklung und Qualitätssicherung...
   Die erste Besonderheit ist die Projektverwaltung, die zum ersten
   Mal bei einem solchen Paket nicht aufgesetzt wirkt...

Amiga Magazin 1/96

   Die Projektverwaltung: Endlich einmal ein Tool, das nicht wie ein Klotz
   am Bein wirkt, sondern wirklich nützlich ist.

Amiga Special 2/96

   Ein schneller Compiler, der leistungsstarke Debugger und die komfortable
   Entwicklungsumgebung sind eine interessante Mischung, wenn es sich um
   professionelle Softwareentwicklung handelt...

Mit der beiliegenden Demoversion können Sie sich selbst davon überzeugen.

Einschränkungen der Demoversion:
================================

Der beiliegende Compiler wird Ihnen zwar große Sourcen durchkompilieren
aber lediglich maximal 10 KByte große Objektcodes schreiben. Sie haben
damit zumindest die Gewißheit, daß Ihre großen Projekte auch kompiliert
werden können.

Der Linker linkt aus den erzeugten Objekten ein Programm mit maximal
20 KByte Größe.

Alle Programmteile von StormC lassen sich NICHT über das CLI starten
sondern sind lediglich in der integrierten Umgebung nutzbar.


Wichtiges zur Installation:
===========================

Die vorliegenden Dateien sind dafür vorgesehen, von CD installiert zu
werden. Wenn Sie die Dateien bereits auf Ihre Festplatte kopiert haben
ist eine Installation nicht notwendig. Sie müssen dann lediglich einen
StormC-Assign in die Datei "user-startup" eintragen, damit die Demo-
Sourcen und StormC-Voreinstellungen unverändert genutzt werden können.


Änderungen und Erweiterungen gegenüber der Preview-Version:
===========================================================

Allgemeine
----------

Die komplette Umgebung ist nun lokalisiert. Die voreingestellte
Sprache ist Englisch. Bei der Installation wird automatisch der
deutschsprachige Catalog kopiert und auch genutzt, wenn Sie
Workbenck-Lokalisierung deutschsprachig eingestellt haben.

Möchten Sie trotz deutschsprachiger Workbench, mit StormC englisch-
sprachig arbeiten, genügt es die Locale-Datei im Verzeichnis
"StormC:StormSYS/CATALOGE/Deutsch/StormCPP.catalog" umzubenennen.

Programmstart:
--------------

Entgegen der Beschreibung im Handbuch auf der Seite 12 wird das Start-
bild nicht angezeigt, wenn für Ihren Workbench-Screen weniger als
64 Farben eingestellt sind. In diesem Fall erscheint ein kleines Fenster,
das Sie darauf hinweist, daß das System noch geladen wird.

Nach dem Laden erscheint ein weiteres Fenster, das Sie darüber informiert,
welche Version Sie benutzen.

Projektverwaltung (StromShell):
-------------------------------

Bei "Datei(en) hinzufügen" ist eine mehrfache Selektion in der Dateiauswahl
möglich.

In die Projektfenster können Workbench-Piktogramme (Appwindow) abgelegt
werden.

Ist ein Sektionstitel markiert, wenn der Menüpunkt "Löschen" angewählt wird,
erfolgt die Rückfrage, ob der Inhalt der ganzen Sektion gelöscht werden soll.
Beantworten Sie die Rückfrage mit "JA", wird die komplette Sektion entfernt.
Die jeweiligen Dateien bleiben selbstverständlich unberührt.

Wird das Debug-Piktogramm oder der Menüpunkt "Debug..." angewählt, obwohl die
Option zum Erzeugen von Debugger-Dateien im Projekt nicht angewählt sind,
erfolgt eine Rückfrage, ob große oder kleine Debug-Dateien angelegt werden
sollen. Die Projekt-Einstellungen bleiben allerdings unbeeinflußt.

Bei Klick auf die Knöpfe "Start..." und "Debug..." aus dem Fehlerfenster,
wird das Fehlerfenster zuerst geschlossen und dann die entsprechende Programm-
funktion ausgeführt.

Beim "Make" bereits übersetzter Projekte wird jetzt zurückgefragt, ob nur
gelinkt oder das ganze Projekt neu kompiliert werden soll.

Der neue Menüpunkt "Bibliothek(en) hinzufügen..." entspricht dem Menüpunkt
"Datei(en) hinzufügen...", setzt aber den Bibliothekssuchpfad des Projekts
als Verzeichnis im ASL-Filerequester und das Pattern "#?.lib". Dadurch
lassen sich deutlich schneller Bibliotheken zum Projekt hinzunehmen.
Einziges Problem: Mehrfachselektionen werden immer alphabetisch sortiert
vom ASL-Requester zurückgegeben, die relevante Reihenfolge von
Bibliotheken kann man also nur erhalten, wenn man jeweils eine Bibliothek
nach der anderen zum Projekt hinzufügt.

Werden Dateien hinzugefügt, die noch nicht existieren, so wird auf Wunsch
die Datei "leer" erzeugt. Als Icon wird jeweils versucht das Icon
"ENV:STORMCPP/def_text.suffix" zu übernehmen, wobei für ".suffix" das Suffix
des Dateinamens eingesetzt wird (z.B. .c oder .h). Dadurch lassen sich
für verschiedene Textarten verschiedene Piktogramme und Texteinstellungen
verwenden.

Die Einstellungen können nun auch von der StormShell gesichert und geladen
werden.

Für den Linker wurden zwei neue Seiten in den Projekteinsteller eingefügt.
Eine weitere erhielt der Optimizer des Compilers.

Beim Programmstart kann so ziemlich jeder Parameter der Shell-Umgebung
eingestellt werden.

Die Codegröße des Executables wird nun nach jedem Compilerlauf neu angezeigt.
Die Codegröße von Bibliotheken wird nun auch angezeigt, wenn die Bibliothek
aus dem Suchpfad der Bibliotheken stammt.

Die Einstellung für 32-bit-korrekte-Multiplikation ist entfallen. Der Compiler
entscheidet selbständig wann welche Multiplikation benötigt wird.

Bei den Einstellern zum C/C+-Compiler ist die Möglichkeit hinzugekommen,
das kleine oder große Code-Modell zu wählen. Der Compiler und der Linker
generieren dann kurze Sprünge (bsr).

Hinweis: Zur aktuellen Demoversion werden allerdings keine Bibliotheken
geliefert, die ein kleines Code-Modell unterstützen. Bei eingeschalteter
Option werden Ihre Programm demnach nicht lauffähig sein.

Bei "Make" und "Compile" werden nun alle Quelltexte automatisch gesichert.

Die Funktionen der Iconleiste sind nun mit den Funktionstasten F1 bis F6 und
F7 bis F10 erreichbar.

Das About-Fenster und das Einstellungsfenster kann auch mit ESC geschlossen
werden. Weitere Shortcuts für About sind "o" und <Return>. Der Use- und der
Cancel-Knopf des Einstellungsfensters sind auch über ihre Shortcuts bedienbar.

Das Fehlerfenster ist nun tastatursteuerbar: Die Shortcuts für "Run", "Debug"
und "Cancel" sind implementiert. Wenn gerade ein "Make" läuft, kann man es
auch mit <ESC> abbrechen, danach, bzw. wenn kein "Make" läuft, wird das
Fenster durch <ESC> geschlossen. Mit "w" kann man die Warnungen an- und
ausschalten.
Per Cursor läuft man durch die Fehlerliste, per <Alt>-Cursor erreicht man
die erste oder letzte Fehlermeldung. <Return> zeigt die Fehlermeldung im
Editor an.

Das Projektfenster ist komplett tastatursteuerbar. Alle 4 Cursortasten
bewegen den Cursor und den Inhalt entsprechend, <Alt> <hoch>/<runter> ermöglicht
den Sprung an den Anfang/Ende der Einträge, <Shift> <rechts>/<links> an den
rechten oder linken Rand. <Return> führt die Aktion entsprechend eines
Doppelklicks aus, <Alt> <Return> die jeweilige Alternative (bisher nur beim
Executable belegt). Backspace bzw. Delete löschen den Eintrag des Cursor
aus dem Projekt und setzen den Cursor auf den nachfolgenden Eintrag.

Debugger (StormRUN):
--------------------

Das im Handbuch beschriebene Debugger-Demo ist leider nur ab
Betriebssystem V39 lauffähig. Wenn Sie V37/38 installiert haben, sollten
Sie mit dem Gadtools-Demo probieren.

Der Menüeintrag "Programm sichern als..." (Seite 42) ist in der
aktuellen Version nicht enthalten, da eine Änderung am Linker eine
entsprechende Funktionalität verhindert hat.

Variablenwerte einfacher Zahl-Typen (char bis long) können in allen
Variablen- und Inspektionsfenstern geändert werden.

Die Wertausgabe ist deutlich schneller, da nur noch die Werte
konvertiert werden, die sich geändert haben.

Die möglichen Breakpoints werden jetzt gefiltert, so daß pro Quelltext-
zeile nur noch max. ein Breakpoint steht, d.h. jeder Schritt führt auf
eine nächste Zeile.

In einem Fall des Breakpoint-Löschens wurde der Cache nicht gelöscht, was
Probleme auf 68040-Rechner zur Folge hatte.

Ein Hexeditor ist eingebaut. Es kann zwischen Byte-, Word- und
Longanzeige hin- und hergeschaltet werden. Die Eingabe von Adressen
(sowohl im Gadget wie auch direkt im Text), Hexdaten und ASCII Daten
ist möglich. Wie im restlichen Debugger wird nur dort etwas angezeigt, bzw
geändert werden, wo gültiges RAM vorhanden ist. Das verhindert
Enforcerhits, aber verbietet auch den Zugriff auf I/O-Bausteine.

Mit der TAB-Taste kann der Cursor von der Adresspalte auf die Hex- und
ASCII-Daten-Spalte und wieder zurück gesetzt werden. Wird in der
Adresspalte die dort angegebene Adresse überschrieben, springt der
Hexeditor automatisch zu der Adresse.

Bei "Save Settings" ("Einstellungen Speichern") werden die Fensterposition
und -größe des Hexeditors auch gespeichert.

Das "Casting" funktioniert. Dazu wurde das Cycle-Gadget in den Variablen-
fenstern gegen ein Stringgadget ausgetauscht (in einer Objektdatei
können schnell mal > 100 Typen auftauchen - mit einem Cyclegadget ist das
nicht handhabbar). Bislang muß in dieses Stringgadget der Typ exakt so eingetippt werden, wie
er ausgegeben würde.

Wenn eine Adresse illegal ist, wird jetzt die betroffene Adresse ausgegeben
(statt "--").

Die Typ-Ausgabe kann bekanntlich in zwei Modi erfolgen: ANSI-C oder
AMIGA-C (mit ULONG, BYTE etc). Diese Unterscheidung kann der Compiler
leider nicht in den Debuginfos ablegen. Derzeit wird die AMIGA-C-
Schreibweise verwendet (kompakter).

Der Start des Programms ist jetzt systemkonformer und -kompatibler. Auch
Aufrufe von Execute() oder SystemTagList() funktionieren jetzt und,
wenn als Ausgabe die Console gewählt wird, kommen Ausgaben der
Befehle auch auf die Console. Das Programm erscheint jetzt auch in der Liste
der CLIs, einen Kommandonamen in den Projekteinstellungen anzugeben ist also
sinnvoll.

Das Resource-Tracking ist nun implementiert. Am Ende des Programms oder nach
einem Kill werden bisher Screens, Windows, Memory, Libraries, Locks und
Files angezeigt, die nicht geschlossen oder freigegeben wurden. Ein
Doppelklick in die Liste führt an die Stelle des Funktionsaufruf. Das
neue Menü "Debug" enthält einen Menüpunkt "Flush Resources"
("Ressourcen freigeben") zur Freigabe dieser Ressourcen.

In manchen Programmen werden sehr viele Ressourcen alloziert, insbesondere
natürlich Speicher. Solche Ressourcen, die also keinen direkten
Funktionsaufruf im Programm besitzen werden nicht angezeigt, aber dennoch
freigegeben.
Ein schönes Beispiel hierfür kann mit der ASL-Library verdeutlicht werden.
Wenn Sie ein Programm "killen", währen ein ASL-Requester offen ist, wird
das ASL-Fenster geschlossen, obwohl der OpenWindow-Aufruf nicht aus Ihrem
Programm sondern aus der ASL-Library gemacht wurde.

Das Ressource-Tracking kann nur den unmittelbare "Caller" ermitteln.
D.h. die Funktion, die den jsr d(a6) enthält. Schon eine Stub-Funktion
für Library-Aufrufe verhindert deshalb die korrekte Anzeige des Aufrufs.
Deshalb ist es angeraten Stub-Funktionen zu vermeiden und "pragma amicall"-
und "tagcall"-Aufrufe zu verwenden.


Editor:
=======

Help-Funktion
-------------

Mit drücken der Help Taste kann man das Wort unter dem Cursor an die
HotHelp-Library (Version 3) übergeben. HotHelp wird dann veranlaßt,
das Schlüsselwort zu suchen und den Hilfetext anzuzeigen!


Lexikon-Dateien und manuelle Farbänderungen / Aufbau der Lexikon-Dateien
------------------------------------------------------------------------
Lexikon (0001)
Amiga Typen
0x00ff0000 0xffffffff 2 0 0
0
VOID
LONG...

Zeile 1: Diese Zeile identifiziert die Datei als Lexikon und trägt
         die Versionsnummer der Lexikon-Datei.

Zeile 2: Kommentarzeile

Zeile 3: RGB-Farbe-Vordergrund RGB-Farbe-Hintergrund (ab V39)
         Vordergrund-Stiftnummer Hintergrund-Stiftnummer (für V37 und V38 erforderlich)
         Stilnummer

Zeile 4: Groß-/Kleinschreibung beachten ein/aus

Zeile 5-...: Inhalte

Ab Betriebssystem-V39 können RGB Farben für die Lexika eingesetzt werden.
Die ersten beiden Zahlen geben in 24 Bit die RGB Farbe für
Schrift- und Hintergrundfarbe an. Dazu können auch Hexadezimalzahlen
mit "0x" am Anfang benutzt werden.

Unter Kickstart V37/V38 werden feste Stiftnummern für die Farbangaben verwendet.
Sie sollten das Compiler-System auf einem Screen mit mindestens 8 Farben
betreiben, da die Farbunterschiede andernfalls zu gering sind.


Für den Editor wurden zwei neue Menüpunkte eingeführt:
1. Einstellungen für den Editor allgemein...
2. ...und für jeden Text im besonderen.

Folgende Editoreinstellungen werden, wie im Fenster zu sehen, bereits
unterstützt: Autosave, Backups, Strip EOL Blanks und Textfontwahl.

Autosave kennt zwei Algorithmen:
Entweder wird alle "n" Minuten ein normales Save durchgeführt, oder
es wird der Text in eine Extradatei gesichert. Der Name dieser
Extradatei wird automatisch durch dem Namen des Dokuments mit einem
angehängten ";0" erzeugt.

Das Sichern in diese Extradatei verändert natürlich nicht den
Textnamen und setzt auch nicht das Modify-Flag "M" zurück.

Zusätzlich kann man beim automatischen Sichern nachfragen lassen, ob
gesichert werden soll.

Hat der Text keinen Namen, wird der Benutzer aufgefordert, den Text zu
sichern, ein Autosave wird dann nicht mehr durchgeführt. Beim Laden eines
Textes wird überprüft, ob eine Autosave-Datei jüngeren Datums existiert, in
diesem Fall bekommt der Benutzer die Wahl welche Datei er laden will, als
Textname wird in beiden Fällen der Originaldateiname gewählt.

Man kann bis zu 9 Backup-Dateien anlegen. Bei jedem Sichern des Textes (auch
bei Autosave auf die Originaldatei) werden die Backup-dateinamen hochgezählt
(die älteste Datei geht dabei eventuell verloren). Die Namen der Backup-
Dateien
ergeben sich aus dem Namen der Originaldatei mit angehängtem ";N", wobei
"N" eine Ziffer zwischen 1 und 9 ist. Die älteste Datei ist die Datei mit
der höchsten Nummer, die jüngste mit der Nummer 1.

Beim Sichern kann man alle "white spaces", d.h. insb. Spaces und Tabs am
Ende der Textzeilen entfernen lassen.

Als Zeichensatz kann jeder nicht-proportionale Zeichensatz angegeben werden.

Achtung: Momentan wird noch keine Fehlermeldung ausgegeben, wenn ein
ungültiger (d.h. nicht existierender oder proportionaler) Zeichensatz
angegeben wird. Es ist empfehlenswert wirklich Zeichensätze auszuwählen,
deren Zeichen alle gleich breit sind. Dies gilt z.B. nicht für den Courier-
Zeichensatz, manche Zeichen sind breiter als die im Font angegebene Breite.
Dadurch kann es zu leichten Darstellungsfehlern am Rand des Texts kommen.

Die Tabulatorweite kann eingestellt werden und wird mit dem Tooltype
TABWIDTH gespeichert.

Automatische Einrückungen können durch "{" und "}" ausgelöst werden.
Bislang wird nur eingerückt (d.h. nur auf das Zeichen "{" reagiert).
Man kann wählen, ob Spaces oder Tabs eingefügt werden, und wieviel
jeweils.

Dabei werden 2 Methoden und ihre Kombinationen unterstützt:

1. Vor der Klammer eingerückt bedeutet, daß beim Eingeben der Klammer
   diese eingerückt wird, wenn vor der Klammer nur Spaces oder Tabs in
   der Zeile stehen. Nach der Klammer wird nach dem nächsten Zeilenum-
   bruch eingerückt, wenn die Klammer das letzte Zeichen der vorherigen
   Zeile ist.

Man kann auswählen, welche Lexika eingefärbt werden und die Syntaxein-
färbungen für C/C++ Kommentare, Strings, Char-Konstanten und Zahl-Konstanten.

Die Einfärbung von C-Kommentaren (/* Test */) funktioniert mit
Einschränkungen:

   geschachtelte Kommentare sind nicht möglich (werdem allerdings vom
   Compiler auch nicht unterstützt, #if 0 ... #endif macht das auch
   besser).

   Die gesamte Einfärberei hat einige Einschränkungen, die jetzt erst
   mit den C-Kommentaren wirklich zum Vorschein kommen: Verschachtelte
   Einfärbungen, z.B. C++-Kommentare, die in einem C-Kommentar stehen,
   können die Einfärbung durcheinander bringen. Werden die einzelnen
   Einfärbungen ausgeschaltet, so wird nur die Farbe ausgeschaltet,
   die Farbmarkierungen werden dennoch gesetzt.

   Also werden z.B. in einem C-Kommentar stehende Strings oder Lexika-
   wörter nicht eingefärbt, egal ob die Einfärbung von C-Kommentaren an
   oder aus ist. Genauso bringt das Ausschalten der Einfärbungen zur Zeit
   keinen Geschwindigkeitszuwachs.

Die Editoreinstellungen werden unter dem Namen "StormSettings.ED"
gespeichert. In dieser ASCII Datei stehen in den letzten Zeilen die
Farben und Register dieser Syntaxeinfärbungen entsprechend der
Reihenfolge im Texteinstellungsfenster und der Syntax, wie sie auch
in den Lexikadateien verwendet wird.

Die Gadgets im Editorfenster sind auch über Tastatur steuerbar. Der
Shortcut ist natürlich von der Lokalisierung abhängig, sollte aber immer
den Qualifier "ctrl" enthalten, um Konflikte mit anderen Shortcuts zu
vermeiden. Der Qualifier "ctrl" wird auch extra behandelt um Konflikte
mit Texteingaben zu vermeiden (was insbesondere CTRL-I und CTRL-M
betrifft, die jetzt nicht mehr äquivalent zu TAB und RETURN sind).

Zwischen der Modified-Anzeige und der Cursorspalten-Anzeige befindet sich
jetzt eine Hilfezeile für alle Gadgets.

Um wirklich von einer 100%igen Tastaursteuerbarkeit zu reden fehlt noch
die Möglichkeit, zwischen den Textfenstern zu springen (bzw. auch die
Projektfenster aktivieren zu können).

Das Find&Replace-Fenster ist nun auch vollständig tastatursteuerbar. Beim
Öffnen des Fensters ist immer das Find-Stringgadget aktiv. Mit <Return> oder
<Tab> wird der String gesucht und das Replace-Gadget aktiviert.
Dort wird mit <Return> oder <Tab> wieder das Findgadget aktiviert. Aus diesen
Stringgadgets heraus kann man alle anderen Gadgets dennoch durch die
Shortcuts bedienen, wahlweise mit der rechten oder auch linken Amiga-Taste
(die linke Amiga-Taste wird erlaubt um Konflikte mit Shortcuts von
Programmen wie NewEdit zu vermeiden, die einen Großteil aller Shortcuts
für sich belegen). Die Shortcuts der Cycle- und Checkboxgadgets
reaktivieren das Stringgadget wieder, die Shortcuts der Buttons aktivieren
das Texteditorfenster. Will man also einen Text suchen und danach in das
Textfenster zurückkehren, so sollte man die Suche mit dem Shortcut von
"Find" (rcommand f) auslösen. <ESC> schließt das Find&Replace-Fenster und
aktiviert das Textfenster.

Die Funktionen aus der StormShell-Toolbar können auch aus dem Editor mit
den Funktionstasten aufgerufen werden.

Eine einfache Print-Funktion ist eingebaut: der ganze Text kann ausgedruckt
werden, dabei wird ein Progress-Fenster angezeigt, in dem der Druck auch
abgebrochen werden kann.

Tastaturbelegung:
-----------------

Shift-Cursor Up/Down
    Bewegt den Cursor auf die erste/letzte Zeile, die im Fenster angezeigt
    ist.

Shift-Cursor Left/Right
    Bewegt den Cursor auf die erste/letzte Spalte in der aktuellen Zeile.

Alt-Cursor Up/Down
    Springt an den Anfang/ans Ende des Textes.

Alt-Cursor Left/Right
    Bewegt den Cursor auf das nächste Wort vor oder auf das letzte hinter
    dem Cursor.

Shift-Delete oder Shift-Backspace
    Löscht die Zeile, auf der der Cursor steht. Die Zeile wird in die Zwischen-
    ablage gespeichert.

Alt-Delete
    Löscht die Zeile ab der Cursor-Position bis zum Ende der Zeile.

Alt-Backspace
    Löscht den Text zwischen der ersten Spalte bis zur Cursorposition.

Help
    Schickt das Wort unter dem Cursor an die Hothelp-Library V3.0 (14. Feb 94).


Compiler:
---------

Im Folgenden werden die Compileränderungen seit der Veröffentlichung
der Preview-Version aufgelistet.

Im ASM-Source wurde bei DS.B o.ä. die allokierte Speichergröße
nur als 16-Bit-Zahl ausgegeben.

Ab 68020 wird der Befehl EXTB.L unterstützt.

Durch Probleme bei Fließkomma-Konstanten mit angehängtem "f"
(z.B. "0.5f") kam es gelegentlich zur Ausgabe von unsinnigen Werten.

Konstrukt "#if defined (xxx)" (die Variante mit Klammern hinter dem
define) führte zu einer Compiler-Panik.

Konvertierung von "unsigned short"/"unsigned byte" auf einen längeren
Typ geschah mittels AND und falscher Bitmaske (genau invers).

Konvertierung von "unsigned byte" auf einen vorzeichenbehafteten
Ganzzahltypen geschah fälschlich mittels EXT.

Aufruf virtueller Funktionen bei Mehrfachvererbung: der
"this"-Pointer der aufgerufenen Funktion wurde in der Variablen
korrigiert, in der er gerade steht - auch wenn es sich dabei um
eine noch benötigte Variable handelt.

"Rundungsfehler" bei Anordnung lokaler Variablen auf dem Stack
führte u.U. zu Variablen an ungeraden Adressen und Stack Frames
ungerader Größe.

"Geschmissene" Exceptions konnten im optimierten Modus meist nicht
mehr aufgefangen werden.

Variable "sym_handlers" (wichtig fürs Exception Handling!) wird
jetzt im Small-Data-Model auch A4-relativ adressiert (endlich
eine sinnvolle Verbindung von Small Data Model und OO-Programmierung).

Wurde in einem Destruktor einer Klasse, die einen Member oder
eine Basisklasse mit Destruktor besitzt, eine Inline-Funktion
aufgerufen, so wurde vom Ende der Inline-Funktion direkt an das
Ende des Destruktors (zur Destruierung von Membern und Basen)
gesprungen.

Beim Abtesten einzelner Bits in Bitfeldern wurde auf das falsche
Bit zugegriffen, was sich auf Umwegen auch beim Konstruieren und
Destruieren virtueller Basisklassen bemerkbar machte.

Als Basiszeiger für die double-Mathe-Lib wird jetzt
"_MathIeeDoubBasBase" statt "lib_MathBase" verwendet.

Die Bibliotheksroutinen "lib_int2double" und "lib_double2int" wurden
durch direkte Aufrufe von IEEEDPFix/IEEEDPFlt ersetzt.

Die Repräsentierung von "long long" wurde compilerseitig auf
eine einleuchtendere Form umgestellt (normales Big Endian).
Außerdem werden für entsprechende Operationen die
Bibliotheksfunktionen Add64, Sub64, Neg64, Cmp64, UMult64,
UDiv64, UMod64, SMult64, SDiv64, SMod64 aufgerufen.

Leere "_INIT_"-Funktionen werden nicht mehr erzeugt.

Bei numerischer Auswertung der Ausdrücke "i != 0" und "!i" wurde
das Ergebnis fälschlich mit AND.W statt AND.L ausmaskiert.

Ein recht globaler Fehler in der Speicherverwaltung verursachte
Adreßfehler auf 68000ern (und ungünstig align'te Daten auf
allen anderen Amigas).

Innerhalb von Konstruktoren wurden generell keine virtuellen
Funktionen aufgerufen, selbst wenn diese eindeutig nicht über
"this" bezogen waren.

Fehler beim Zugriff auf Strukturen von mehr als 32 KByte Größe:
Adreßoffsets >32767 wurden falsch codiert und führten zu einem
Assemblerfehler.


Fehler im Zusammenhang mit MagicMenu und möglicherweise mit SUN-Mouse-Utilities
-------------------------------------------------------------------------------

Bei installiertem MagicMenu friert der Bildschirm ein, wenn bei aktivem
Piktogramm-Fenster die rechte Maustaste gedrückt wird und sich der
Mauszeiger über einem Piktogramm befindet. Durch eine Inkonformität von MagicMenu
werden Mousemove-Nachrichten geschickt, obwohl die rechte Maustaste gedrückt
ist. In diesem Fall versucht dann die StormShell die Hilfezeile im Fenster
auszugeben und erzeugt dadurch das Einfrieren des Bildschirms. Im Falle von
MagicMenu dauert es ca. 10 Sekunden und man kann normal weiterarbeiten.

Zu ähnlichen Problemen kann es auch mit verschiedenen SUN-Mouse Utilities
kommen.



Bei Fragen wenden Sie sich bitte an:

      HAAGE & PARTNER Computer GmbH
      Mainzer Straße 10A
      61191 Rosbach v.d.H.

      Tel: [phone]
      Fax: [phone]

      Compuserve: 100654,3133
      Internet: [e-mail]
      Web Page: http://home.pages.de/~haage



Zum Schluß möchten wir uns bei unseren aktiven Betatestern bedanken.

Vielen Dank an:

    Dietmar Augustin
    Olaf Barthel
    Michael Bergmann
    Holger Burkarth
    Thomas Bayen
    Bernhard Büchter
    Michael Donner
    Torsten Ebeling
    David Göhler
    Clemens Marschner
    Alexander Pratsch
    Andreas Pfohl
    Constantin Rack
    Michael Rock
    Jürgen Schildmann
    Carsten Schlote
    Stephan Schüerholz
    Thomas Wilhelmi


(c) 1995/1996 HAAGE & PARTNER Computer GmbH